The transmission control protocol (TCP) is a widely used protocol in the Internet protocol suite. Conceptually, it is a part of the transport layer in the network stack in the Internet Protocol Suite. The TCP provides a reliable stream of data between applications running on hosts communicating over an IP network. Key functions performed by the TCP include dividing the data passed to it from the application layer into appropriately sized chunks for the network layer, acknowledging received packets, setting timeouts to make certain the other end acknowledges packets that are sent, and so forth. TCP is used for data transfer in a variety of applications including file transfer, the World Wide Web, data streaming, email, and so forth.
A TCP connection is established between a sender and receiver using a three-way or 3-step handshake. During this process, full-duplex communication is established by: i) the sender transmitting a TCP segment with a Synchronize Sequence Number (SYN); ii) the receiver sending an acknowledge (ACK) message to the sender's SYN containing the receiver's SYN (i.e., a SYN+ACK message); and iii) the sender sending an ACK to the receiver's SYN.
Once a TCP connection is established, data is transferred between devices using a sliding window acknowledgement system. The TCP transmitter includes sequence numbers in the data it sends. The TCP receiver uses the sequence numbers to acknowledge data segments it has received. The rate at which a TCP transmitter can send data to a TCP receiver is limited by a send window that defines a maximum number of unacknowledged bytes the transmitter is allowed to have at a time. As the TCP transmitter receives acknowledgments, transmitted data may be reclassified from “sent and unacknowledged” to “sent and acknowledged,” which permits the send window to “slide” to send more data. If a data segment is lost in transit, the TCP transmitter will not receive an acknowledgement for the segment and will retransmit it.
The TCP transmitter dynamically adjusts the size of the window based on network conditions, but the window has an upper bound determined by the TCP receiver's advertised available buffer space. The TCP throughput possible with a particular window size is determined by the rate at which acknowledgments are received. With any particular window size, longer acknowledgment time means lower throughput. The time it takes for TCP data to be acknowledged is known as the TCP round trip time (RTT).
Although TCP was designed to be flexible and work over a wide variety of communication links, the throughput possible across the TCP connection is affected by the characteristics of the link in which it is used. In particular, TCP protocol throughput performance may suffer in environments with high packet loss and high latency. An example of such an environment is an environment that includes a high latency link, such as a geosynchronous satellite link. Inherently, there will be about a 125 ms delay for data packets to travel at the speed of light from the earth's surface to a satellite positioned above the equator. Altogether, this creates a minimum RTT between transmitter and receiver of a data session of at least 500 ms. However, the TCP protocol was designed for use on terrestrial networks having a substantially shorter average latency.
A class of methods for improving the performance of TCP sessions over high latency environments (e.g., satellite links) involve Performance Enhancing Proxies (PEPs), which are techniques that change the TCP header data before and after the high latency link (e.g., satellite link) in order to mask the high latency of the high latency link from the TCP session. One PEP technique is TCP spoofing, which involves an intermediate network device (e.g., a satellite modem/router at the customer side or a device at the satellite carrier's Network Operations Center) imitating a TCP session by sending locally generated TCP packet acknowledgments. FIG. 1 illustrates an example implementation of TCP spoofing in a satellite network. As illustrated, in such an implementation, the spoofing device (in this example, a router) locally acknowledges receipt of a data packet from a sender (e.g., a client computer or server) as if it were the receiver. The local acknowledgments reduce the RTT perceived by the TCP sender, allowing the TCP sender to transmit data more quickly, thereby improving throughput.
TCP spoofing introduces the following benefits for a TCP connection. First, it speeds up the TCP connection set-up by spoofing the TCP three-way handshake to hide the high latency (e.g. satellite) resulting from the RTT of the connection setup process. Second, it speeds up transmit window growth to increase throughput significantly faster. Third, it provides recovery from packets lost between the remote host and the terminal and/or between the IP Gateway and the Internet host using low latency (i.e, terrestrial) RTTs, again hiding the high (e.g. satellite) round trip latency. Additionally, it provides recovery from packets lost between the terminal and the IP Gateway transparently to the end hosts (i.e. without causing changes to the TCP connection congestion window).
In order to implement TCP spoofing, the spoofing device utilizes memory resources (e.g., a storage buffer) to store data segments until they are acknowledged across the link and allow for the retransmission of data segments for which no acknowledgement is received. However, the memory resources available to a TCP spoofer are finite. At some point, it becomes impossible to spoof a new TCP connection because of the number of TCP connections already being spoofed. This problem is avoided (but not solved) by throwing more resources at the TCP spoofer. But, there are platform specific limits as to how far this can be taken. When no resources are available for a new TCP connection, the connection must be forwarded unspoofed, without mitigation for the challenging elements of the environment.
Original TCP spoofing implementations allocated TCP spoofing resources (i.e., buffer space, connection control blocks, etc.) dynamically as TCP connections were established and detected by the TCP spoofing gateway, without taking into account the type of application using the TCP connection. In such implementations, all TCP connections, regardless of whether or not they will benefit from spoofing (i.e., will benefit from the high throughput), are spoofed up until all the TCP spoofing resources have been allocated. Any additional TCP connections which are detected must pass through unspoofed, even if they are associated with applications which require high throughput.
More recently, selective TCP spoofing has been implemented using classification rules. However, in such implementations, classification rules are statically applied at all times, ignoring both host characteristics and spoofing resource availability. These classification rules are aimed at never spoofing certain types of applications irrespective of TCP spoofing resource availability.